System and method for enabling users to interact in a virtual space

ABSTRACT

The present invention provides a highly scalable architecture for a three-dimensional graphical, multi-user, interactive virtual world system. In a preferred embodiment a plurality of users interact in the three-dimensional, computer-generated graphical space where each user executes a client process to view a virtual world from the perspective of that user. The virtual world shows avatars representing the other users who are neighbors of the user viewing the virtual word. In order that the view can be updated to reflect the motion of the remote user&#39;s avatars, motion information is transmitted to a central server process which provides positions updates to client processes for neighbors of the user at that client process. The client process also uses an environment database to determine which background objects to render as well as to limit the movement of the user&#39;s avatar.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of and claims priority from U.S.patent application Ser. No. 14/133,616, filed Dec. 18, 2013, nowallowed. The U.S. patent application Ser. No. 14/133,616 is acontinuation of and claims priority from U.S. patent application Ser.No. 13/162,540, filed Jun. 16, 2011, now U.S. Pat. No. 8,640,028. TheU.S. patent application Ser. No. 13/162,540 is a continuation of andclaims priority from U.S. patent application Ser. No. 12/406,968, filedMar. 19, 2009, now U.S. Pat. No. 8,082,501. The U.S. patent applicationSer. No. 13/162,540 is also a continuation of and claims priority fromU.S. patent application Ser. No. 12/406,970, filed Mar. 19, 2009, nowU.S. Pat. No. 8,145,998. The U.S. patent application Ser. No. 13/162,540is also a continuation of and claims priority from U.S. patentapplication Ser. No. 13/083,504, filed Apr. 8, 2011, now U.S. Pat. No.8,161,385. The U.S. patent application Ser. No. 13/162,540 is also acontinuation of and claims priority from U.S. patent application Ser.No. 13/084,195, filed Apr. 11, 2011, now U.S. Pat. No. 8,407,592. Eachof the application Ser. Nos. 12/406,968, 12/406,970, 13/083,504, and13/084,195 is a continuation of and claims priority from U.S. patentapplication Ser. No. 12/353,218, filed Jan. 13, 2009, now U.S. Pat. No.7,945,856; which is a continuation of and claims priority from U.S.patent application Ser. No. 11/591,878, filed Nov. 2, 2006, now U.S.Pat. No. 7,493,558; which is a continuation of and claims priority fromU.S. patent application Ser. No. 09/632,154, filed Aug. 3, 2000, nowU.S. Pat. No. 7,181,690; which is a continuation of and claims priorityfrom U.S. patent application Ser. No. 08/747,420, filed Nov. 12, 1996,now U.S. Pat. No. 6,219,045; which claims priority from U.S. ProvisionalPatent Application Ser. No. 60/020,296, filed Nov. 13, 1995.

The disclosures of all of the foregoing patent documents areincorporated by reference as if fully set forth herein, includingspecifications, figures, abstracts, claims, tables, appendices, and allother matter of each of the patent documents.

BACKGROUND

The present invention relates to the field of packet communications.More specifically, in one embodiment the invention provides an efficientcommunications network for client-server networks with large numbers ofclients.

A client-server network is a network where one or more servers arecoupled to one or more clients over a communications channel. Typically,each server and each client is assigned an address so that each candetermine which network messages are directed to it. While such a systemmay have only one server, it typically has many clients. A server objectis one which waits for a request from a client object and then performssome service in response to the client request. A client is an objectthat makes the request. The designation of a particular object (computerhardware and/or software process) as a “server” object or a “client”object is not fixed. Thus, a given object can be a server for someservices and a client of other services.

A typical computer network has one or more file and print servers with anumber of clients, where the clients are the desktop computers orworkstations of the computer users, all coupled to a high-speed networkcable. Client-server communications in such a network are easily handledfor several reasons. When clients are not all communicating with theserver at once the server need not be designed to handle all the clientsat one time. Another reason is that the network traffic is much lessthan the network capacity furthermore, the clients in a typical computernetwork need not necessarily be communicating in real-time with theserver. However, where many client machines or processes arecommunicating with each other in real-time through the server, severalproblems arise.

For example, where a client-server system is used for real-time exchangeof information, such as a distributed virtual reality network whereusers at client machines visually and aurally interact with other usersat other client machines, communication is much more difficult,especially where the information is high-bandwidth data such as audiostreams, graphic images and image streams. One application of such aclient-server system is for game playing, where the positions andactions of each user need to be communicated between all the players toinform each client of the state changes (position, actions, etc.) whichoccurred at the other clients. The server might maintain global stateinformation and serve as a data server for the clients as they requestvisual, program and other data as the game progresses.

Some game systems use a peer-to-peer architecture. In a peer-to-peerarchitecture, a copy of the data which is common to all clients is keptby the client and information which needs to pass between clients isbroadcast over the network. This limits the number of clients which canbe connected to the network, because the number of messages passingbetween clients is on the order of the square of the number of clients.With true broadcasting, one message is sent and all clients listen forit, but not all network topologies can handle broadcasts. Where lessthan all the clients are participating in a game, for example, messagescannot be broadcast because there are clients which should not bereceiving the broadcast message. Instead, the broadcast between theplayers is handled by generating one message to each player client.

This architecture is further limited where the network is not adedicated network, but is an open network, such as the Internet. As usedherein, the term “Internet” refers to the global inter-network ofnetworks which communicates primarily using packets sent according toTCP/IP (Transport Control Protocol/Internet Protocol) standards wellknown in the art of computer intercommunication. With Internetcommunications, true broadcasting is not even possible because thenetwork's extent is not known or fixed. Thus, messages to all playersmust be sent as separate messages. An additional problem with Internetcommunications is that packet delivery is not guaranteed nor is it evenas reliable as a dedicated network.

Therefore, what is needed is an efficient system for communicationbetween many client systems over dedicated or open networks to providegraphical interaction between users operating the client systems.

SUMMARY

The present invention provides a highly scalable architecture for athree-dimensional graphical, multi-user, interactive virtual worldsystem. In a preferred embodiment a plurality of users interact in thethree-dimensional, computer-generated graphical space where each userexecutes a client process to view a virtual world from the perspectiveof that user. The virtual world shows avatars representing the otherusers who are neighbors of the user viewing the virtual word. In orderthat the view can be updated to reflect the motion of the remote user'savatars, motion information is transmitted to a central server processwhich provides positions updates to client processes for neighbors ofthe user at that client process. The client process also uses anenvironment database to determine which background objects to render aswell as to limit the movement of the user's avatar.

A further understanding of the nature and advantages of the inventionsherein may be realized by reference to the remaining portions of thespecification and the attached drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a client screen view in a virtual world system according tothe present invention.

FIG. 2 is a logical block diagram of the hardware elements of a virtualworld system.

FIG. 3 is a block diagram of the elements of one embodiment of a virtualworld system, showing two clients and one server.

FIG. 4 is a more detailed block diagram of a client system according toone embodiment of the present invention.

FIG. 5 is an illustration of an avatar.

DESCRIPTION OF THE PREFERRED EMBODIMENT

Although the preferred embodiment of the present invention can be usedin a variety of applications, as will be apparent after reading thebelow description, the preferred embodiment is described herein usingthe example of a client-server architecture for use in a virtual world“chat” system. In this chat system, a user at each client systeminteracts with one or more other users at other client systems byinputting messages and sounds and by performing actions, where thesemessages and actions are seen and acted upon by other clients. FIG. 1 isan example of what such a client might display.

Each user interacts with a client system and the client system isnetworked to a virtual world server. The client system are desktopcomputers, terminals, dedicated game controllers, workstations, orsimilar devices which have graphical displays and user input devices.The term “client” generally refers to a client machine, system and/orprocess, but is also used to refer to the client and the usercontrolling the client.

FIG. 1 is an illustration of a client screen display 10 seen by one userin the chat system. Screen display 10 is shown with several stationaryobjects (wall, floor, ceiling and clickable object 13) and two “avatars”18. Each avatar 18 is a three dimensional figure chosen by a user torepresent the user in the virtual world. Each avatar 18 optionallyincludes a label chosen by the user. In this example, two users areshown: “Paula” and “Ken”, who have chosen the “robot” avatar and thepenguin avatar, respectively. Each user interacts with a client machine(not shown) which produces a display similar to screen display 10, butfrom the perspective of the avatar for that client/user. Screen display10 is the view from the perspective of a third user, D, whose avatar isnot shown since D's avatar is not within D's own view. Typically, a usercannot see his or her own avatar unless the chat system allows “our ofbody” viewing or the avatar's image is reflected in a mirrored object inthe virtual world.

Each user is free to move his or her avatar around in the virtual world.In order that each user see the correct location of each of the otheravatars, each client machine sends its current location, or changes inits current location, to the server and receives updated positioninformation of the other clients.

While FIG. 1 shows two avatars (and implies a third), typically manymore avatars will be present. A typical virtual world will also be morecomplex than a single room. The virtual world view shown in FIG. 1 ispart of a virtual world of several rooms and connecting hallways asindicated in a world map panel 19, and may include hundreds or users andtheir avatars. So that the virtual world is scalable to a large numberof clients, the virtual world server must be much more discriminating asto what data is provided to each clients. In the example of FIG. 1,although a status panel 17 indicates that six other avatars are present,many other avatars are in the room, but are filtered out for crowdcontrol.

FIG. 2 is a simplified block diagram of the physical architecture of thevirtual world chat system. Several clients 20 are shown which correspondwith the users controlling avatars 18 shown in screen display 10. Theseclients 20 interact with the virtual world server 22 as well as theother clients 20 over a network 24 which, in the specific embodimentdiscussed here, is a TCP/IP network such as the Internet. Typically, thelink from the client is narrowband, such as 14.4 kbps (kilobits/second).

Typically, but not always, each client 20 is implemented as a separatecomputer and one or more computer systems are used to implement virtualworld server 22. As used here, the computer system could be a desktopcomputer as are well known in the art, which use CPU's available fromIntel Corporation, Motorola, SUN Microsystems, Inc., InternationalBusiness Machines (IBM), or the like and are controlled by operationsystems such as the Windows® program which runs under the MS-DOSoperating system available from Microsoft Corporation, the Macintosh®O/S from Apple Computer, or the Unix® operating system available from avariety of vendors. Other suitable computer systems include notebookcomputers, palmtop computers, hand-held programmable computing devices,special purpose graphical game machines (e.g., those sold by Sony, SEGA,Nintendo, etc.), workstations, terminals, and the like.

The virtual world chat system is described below with reference to atleast two hypothetical users, A and B. Generally, the actions of thesystem are described with reference to the perspective of user A. It isto be understood that, where appropriate, what is said about user Aapplies to user B, and vice versa, and that the description below alsoholds for a system with more than two users (by having multiple users Aand/or B). Therefore, where an interaction between user A and user B isdescribed, implied therein is that the interaction could take place justas well with users A and B having their roles reversed and could takeplace in the same manner between user A and user C, user D, etc. Thearchitecture is described with reference to a system where each user isassociated with their own client computer system separate from thenetwork and servers, however a person of ordinary skill in the art ofnetwork configuration would understand, after reading this description,how to vary the architecture to fit other physical arrangements, such asmultiple users per computer system or a system using more complexnetwork routing structures than those shown here. A person of ordinaryskill in the art of computer programming will also understand that wherea process is described with reference to a client or server, thatprocess could be a program executed by a CPU in that client or serversystem and the program could be stored in a permanent memory, such as ahard drive or read-only memory (ROM), or in temporary memory, such asrandom access memory (RAM). A person of ordinary skill in the art ofcomputer programming will also understand how to store, modify andaccess data structures which are shown to be accessible by a client orserver.

Referring now to FIG. 3, a block diagram is shown of a world system 54in which a user A, at a first client system 60 (client A), interactswith a user B at a second client system 60 (client B) via a server 61.Client system 60 includes several databases, some of which are fixed andsome of which are modifiable. Client system 60 also includes storage forprogram routines. Mechanisms for storing, reading and modifying data oncomputers such as client system 60 are well known in the art, as aremethods and means for executing programs and displaying graphicalresults thereof. One such program executed by client system 60 is agraphical rendering engine which generates the user's view of thevirtual world.

Referring now to FIG. 4, a detailed block diagram of client 60 used by auser, A is shown. The other clients used by other users are similar toclient 60.

The various components of client 60 are controlled by CPU 100. A networkpacket processor 102 sends and receives packets over network connection80. Incoming packets are passed to a network message processor 104 whichroutes the message, as appropriate to, a chat processor 106, a customavatar images-database 108, a short object ID lookup table 110, or aremote avatar position table 112. Outgoing packets are passed to networkpacket processor 102 by network message processor in response tomessages received from chat processor 106, short object ID lookup table110 or a current avatar position register 114.

Chat processor 106 receives messages which contain conversation (textand/or audio) or other data received from other users and sends outconversation or other data directed to other users. The particularoutgoing conversation is provided to chat processor 106 by input devices116, which might include a keyboard, microphones, digital video cameras,and the like. The routing of the conversation message depends on aselection by user A. User A can select to send a text message toeveryone whose client is currently on line (“broadcast”), to only thoseusers whose avatars are “in range” of A's avatar (“talk”), or to only aspecific user (“whispering”). The conversation received by chatprocessor 106 is typically received with an indication of thedistribution of the conversation. For example, a text message might havea “whisper” label prepended to it. If the received conversation isaudio, chat processor 106 routes it to an audio output device 118. Audiooutput device 118 is a speaker coupled to a sound card, or the like, asis well known in the art of personal computer audio systems. If thereceived conversation is textual, it is routed to a rendering engine 120where the text is integrated into a graphical display 122.Alternatively, the text might be displayed in a region of display 122distinct from a graphically rendered region.

Current avatar position register 114 contains the current position andorientation of A's avatar in the virtual world. This position iscommunicated to other clients via network message processor 104. Theposition stored in register 114 is updated in response to input frominput devices 116. For example, a mouse movement might be interpreted asa change in the current position of A's avatar. Register 114 alsoprovides the current position to rendering engine 120, to informrendering engine 120 of the correct view point for rendering.

Remote avatar position table 112 contains the current positions of the“in range” avatars near A's avatar. Whether another avatar is in rangeis determined a “crowd control” function, which is needed in some casesto ensure that neither client 60 nor user A get overwhelmed by thecrowds of avatars likely to occur in a popular virtual world.

Server 61 maintains a variable, N, which sets the maximum number ofother avatars A will see. Client 60 also maintains a variable, N′, whichmight be less than N, which indicates the maximum number of avatarsclient 60 wants to see and/or hear. The value of N′ can be sent byclient 0 to server 61. One reason for setting N′ less than N is whereclient 60 is executed by a computer with less computing power than anaverage machine and tracking N avatars would make processing andrendering of the virtual world too slow. Once the number of avatars tobe shown is determined, server 61 determines which N avatars are closestto A's avatar, based on which room of the world A's avatar is in and thecoordinates of the avatars. This process is explained in further detailbelow. If there are less than N avatars in a room which does not haveopen doors or transparent walls and client 60 has not limited the viewto less than N avatars, A will see all the avatars in the room. Thoseavatars are thus “neighboring” which means that client 60 will displaythem.

Generally, the limit set by server 61 of N avatars and the limit set byclient 60 of N′ avatars control how many avatars A sees. If server 61sets a very high value for N, then the limit set by client 60 is theonly controlling factor. In some cases, the definition of “neighboring”might be controlled by other factors besides proximity. For example, thevirtual world might have a video telephone object where A can speak withand see a remote avatar. Also, where N or more unfriendly avatars are inclose proximity to A's avatar and they persist in following A's avatar,A will not be able to see or communicate with other, friendly avatars.To prevent this problem, user A might have a way to filter out avatarson other variables in addition to proximity, such as user ID.

In any case, remote avatar position table 112 contains an entry for eachneighboring avatar. That entry indicates where the remote avatar is (itsposition), its orientation, a pointer to an avatar image, and possibleother data about the avatar such as its user's ID and name. The positionof the avatar is needed for rendering the avatar in the correct place.Where N′ is less than N, the client also uses position data to select N′avatars from the N avatars provided by the server. The orientation isneeded for rendering because the avatar images are three-dimensional andlook different (in most cases) from different angles. The pointer to anavatar image is an index into a table of preselected avatar images,fixed avatar image database 71, or custom avatar images database 108. Ina simple embodiment, each avatar image comprises M panels (where M isgreater than two with eight being a suitable number) and the i-th panelis the view of the avatar at an angle of 360*i/M degrees. Custom avatarimages are created by individual users and sent out over networkconnection 80 to other clients 60 which are neighbors of the customavatar user.

Short object ID lookup table 110 is used to make communications overnetwork connection 80 more efficient. Instead of fully specifying anobject, such as a particular panel in a particular room of a worldavatar, a message is sent from server 61 associating an object's fullidentification with a short code. These associations are stored in shortobject ID lookup table 110. In addition to specifying avatars, the shortobject ID's can be used to identify other objects, such as a panel in aparticular room.

Short object ID lookup table 110 might also store purely localassociations. Although not shown in FIG. 4, it is to be understood thatconnections are present between elements shown and CPU 100 as needed toperform the operations described herein. For example, an unshownconnection would exist between CPU 100 and short object ID lookup table110 to add, modify and delete local short object ID associations.Similarly, CPU 100 has unshown connections to rendering engine 120,current avatar position register 114 and the like.

Client 60 includes a rooms database 70, which describes the rooms in thevirtual world and the interconnecting passageways. A room need not be anactual room with four walls, a floor and a ceiling, but might be simplya logical open space with constraints on where a user can move his orher avatar. CPU 100, or a specific motion control process, limits themotion of an avatar, notwithstanding commands from input devices 116 todo so, to obey the constraints indicated in rooms database 70. A usermay direct his or her avatar through a doorway between two rooms, and ifprovided in the virtual world, may teleport from one room to another.

Client 60 also includes an audio compressor/decompressor 124 and agraphics compressor/decompressor 126. These allow for efficienttransport of audio and graphics data over network connection 80.

In operation, client 60 starts a virtual world session with user Aselecting an avatar from fixed avatar image database 71 or generating acustom avatar image. In practice, custom avatar image database 108 mightbe combined with fixed avatar image database 71 into a modifiable avatarimage database. In either case, user A selects an avatar image and apointer to the selected image is stored in current avatar positionregister 114. The pointer is also communicated to server 61 via networkconnection 80. Client 60 also sends server 61 the current position andorientation of A's avatar, which is typically fixed during theinitialization of register 114 to be the same position and orientationeach time.

Rooms database 70 in a fixed virtual world is provided to the user withthe software required to instantiate the client. Rooms database 70specifies a list of rooms, including walls, doors and other connectingpassageways. Client 60 uses the locations of walls and other objects todetermine how A's avatar's position is constrained. Rooms database 70also contains the texture maps used to texture the walls and otherobjects. Avatar database 71 specifies the bitmaps used to render variouspredefined avatars provided with the client system. Using rooms database70 and the locations, tags and images of all the neighboring avatars,then a view of objects and other avatars in the virtual world can berendered using the room primitives database and the avatar primitivesdatabase.

Instead of storing all the information needed for rendering each roomseparately, a primitives database can be incorporated as part of roomsdatabase 70. The entries in this primitives database describe how torender an object (e.g., wall, hill, tree, light, door, window, minor,sign, floor, road). With the mirrored primitive, the world is notactually mirrored, just the avatar is. This is done by mapping theavatar to another location on the other side of the mirrored surface andmaking the mirror transparent. This will be particularly useful wherecustom avatars are created, or where interaction with the environmentchanges the look of the avatar (shark bites off arm, etc.).

The typical object is inactive, in that its only effect is being viewed.Some objects cause an action to occur when the user clicks on theobject, while some objects just take an action when their activatingcondition occurs. An example of the former is the clickable objects 13shown in FIG. 1 which brings up a help screen. An example of the latteris the escalator object. When a user's avatar enters the escalator'szone of control, the avatar's location is changed by the escalatorobject automatically (like a real escalator).

The avatars in fixed avatar image database 71 or custom avatar imagesdatabase 108 contain entries which are used to render the avatars. Atypical entry in the database comprises N two-dimensional panels, wherethe i-th panel is the view of the avatar from an angle of 360*i/Ndegrees. Each entry includes a tag used to specify the avatar.

In rendering a view, client 60 requests the locations, orientations andavatar image pointers of neighboring remote avatars from server 61 andthe server's responses are stored in remote avatar position table 112.Server 61 might also respond with entries for short object ID lookuptable 110. Alternatively, the updates can be done asynchronously, withserver 61 sending periodic updates in response to a client request orautomatically without request.

Rendering engine 120 then reads register 114, remote avatar positiontable 112, rooms database 70 and avatar image databases as required, andrendering engine 120 renders a view of the virtual world from the viewpoint (position and orientation) of A's avatar. As input devices 116indicate motion, the contents of register 114 are updated and renderingengine 120 re-renders the view. Rendering engine 120 might periodicallyupdate the view, or it may only update the view upon movement of eitherA's avatar or remote avatars.

Chat processor 106 accepts chat instructions from user A via inputdevices 116 and sends conversation messages to server 61 fordistribution to the appropriate remote clients. If chat processor 106receives chat messages, it either routes them to audio output device 118or to rendering engine 120 for display.

Input devices 116 supply various inputs from the user to signal motion.To make movement easier and more natural, client 60 performs severalunique operations. One such operation is “squared forward movement”which makes it easier for the user to move straight. Unlike ordinarymouse movements, where one mouse tick forward results in an avatarmovement forward one unit and one mouse tick to the left or rightresults in side movement of one unit, squared forward movement squaresthe forward/backward ticks or takes the square root of the sidewaysticks or divides by the number of forward/backward ticks. For example,if the user moves the mouse F mouse ticks forward, the avatar moves Fscreen units forward, whereas if the user moves the mouse F mouse unitsforward and L mouse units to the left, the avatar moves F units forwardand L/F screen units to the left. For covering non-linear distances, (F,L) mouse units (i.e., F forward, L to the side) might translate to (F²,L) screen units.

As mentioned above, user input could also be used to signal a desire forinteraction with the environment (e.g. clicking on a clickable object).User input could also be used to signal for a viewpoint change (e.g.head rotation without the avatar moving, chat inputs and login/logoutinputs.

In summary, client 60 provides an efficient way to display a virtual,graphical, three-dimensional world in which a user interacts with otherusers by manipulating the positions of his or her avatar and sends chatmessages to other users.

Network connection 80 will now be further described. Commonly, networkconnection 80 is a TCP/IP network connection between client 60 andserver 61. This connection stays open as long as client 60 is logged in.This connection might be over a dedicated line from client 60, or mightbe a SLIP/PPP connection as is well known in the art of networkconnection.

The network messages which pass over network connection 80 betweenclient 60 and server 61 are described immediately below briefly, with amore detailed description in Appendix A. Three main protocols exist formessaging between client 60 and server 61: 1) A control protocol, 2) adocument protocol, and 3) a stream protocol. The control protocol isused to pass position updates and state changes back and forth betweenclient 60 and server 61. The control protocol works with a very lowbandwidth connection.

The document protocol is used between client 60 and server 61 todownload documents (text, graphics, sound, etc.) based on UniformResource Locators (URLs). This protocol is a subset of the well-knownHTTP (Hyper-Text Transport Protocol). This protocol is used relativelysparingly, and thus bandwidth is not as much of a concern as it is withthe control protocol. In the document protocol, client 60 sends adocument request specifying the document's URL and server 61 returns acopy of the specified document or returns an error (the URL wasmalformed, the requested URL was not found, etc.).

The stream protocol is used to transfer real-time video and audio databetween client 60 and server 61. Bandwidth is not as much a concern hereas it is with the control protocol.

Each room, object, and user in a virtual world is uniquely identified bya string name and/or numerical identifier. For efficient communications,string names are not passed with each message between client 60 andserver 61, but are sent once, if needed, and stored in short object IDlookup table 110. Thereafter, each message referring to an object or auser need only refer to the short object ID which, for 256 or lessobjects, is only an 8-bit value. Rooms are identified by a uniquenumerical value contained in two bytes (16 bits).

The control protocol is used by client 60 to report the location andstate information, such a “on” and “off” states for a light object orother properties, for user A to server 61 and is used by server 61 tosend updates to client 60 for remote avatar position table 112 andupdates of characteristics of other objects in the virtual worldenvironment. Server 61 also uses the control protocol to update client61 on which avatars are in range of A's avatar. To allow for piecemealupgrading of a virtual world system, client 60 will not err upon receiptof a message it does not understand, but will ignore such as message, asit is likely to be a message for a later version of client 60.

Each message is formed into a control packet and control packets assumea very brief form so that many packets can be communicated quickly overa narrowband channel. These control packets are not to be confused withTCP/IP or UDP packets, although a control packet might be communicatedin one or more TCP/IP or UDP packets or more than one control packetmight be communicated in one TCP/IP packet. The format of a controlpacket is shown in Table

TABLE 1 FIELD SIZE DESCRIPTION PktSize UInt8 Number of bytes in thecontrol packet (including Pktsize byte) ObjID UInt8 (ShortObjID)Identifies the object to which 0string (LongObjID) the command isdirected Command UInt8 + arguments Describes what to do with the object“UInt8” is an 8-bit unsigned integer. “0string” is a byte containingzero (indicating that a long object identifier is to follow) followed bya string (which is defined to be a byte containing the size of thestring followed by the characters of the string). Each control packetcontains one command or one set of combined commands. The ObjID field isone of two formats: either a ShortObjID (0 to 255) or a LongObjID (astring). The ObjID field determines which object in the client's worldwill handle the command. Several ShortObjID values are preassigned asshown in Table 2.

TABLE 2 ShortObjID Object 0 A short ObjID of 0 indicates that a LongObjID follows 1 The Client's Avatar 254 CO—Combine Object 255PO—Protocol Object

The other ShortObjID values are assigned by server 61 to representobjects in the virtual world. These assignments are communicated toclient 60 in a control packet as explained below. The assignments arestored by client 60 in short object ID lookup table 110. The ShortObjIDreferences are shorthand for an object which can also be referenced by aLongObjID.

When commands are directed at the CO object (ShortObjID=254), thosecommands are interpreted as a set of more than one command. Whencommands are directed at the PO object, the command applies to thecommunications process itself. For example, the REGOBJIDCMD command,which registers an association between a ShortObjID and a LongObjID, isdirected at the PO object. Upon receipt of this command, client 60registers the association in the short object ID lookup table.

A command takes the form of a command type, which is a number between 0and 255, followed by a string of arguments as needed by the particularcommand.

The CO object is the recipient of sets of commands. One use of a set ofcommands is to update the positions of several avatars without requiringa separate control packet for each avatar, thus further saving networkbandwidth. The form of the command is exemplified by the followingcommand to move objects 2 and 4 (objects 2 and 4 are remote avatars):

-   -   S>C CO SHORTLOCCMD [2 −10 −20 −90] [4 0 0 90]

In the above control packet, “S>C” indicates the direction of the packet(from server to client), CO is the object, SHORTLOCCMD is the commandtype, and the command type is followed by three abbreviated commands.The above control packet requires only fifteen bytes: one for packetsize (not shown), one for the CO object ID, one for the command type andtwelve for the three abbreviated commands. Note that the “S>C” indicatoris not part of the control packet. The position of the boundariesbetween commands (indicated above with brackets, which are not actuallycommunicated) is inferred from the fact that the SHORTLOCCMD commandtype requires four byte-wide arguments. Each abbreviated command in acommand set is the same size, for easy parsing of the commands by theCO. Examples of abbreviated commands for which a CO command is usefulare the Teleport, Appear, Disappear, and ShortLocation commands. Thesecommands, and other commands, are described in more detail in AppendixA. Appendix A also shows the one byte representation of SHORTLOCCMD aswell as the one byte representations of other command types. Thecontents of control packets described herein are shown in a readableform, however when transmitted over network connection 80, the controlpackets are compacted using the values shown in Appendix A.

The following examples show various uses of control packets. In thefollowing sequences, a line beginning with “S>C” denotes a controlpacket sent from server 61 to client 60, which operates user A's avatarand interacts with user A. Similarly, a, line beginning with “C>S”denotes a control packet sent from client 60 to server 61. Note that allof the lines shown below omit the packet size, which is assumed to bepresent at the start of the control packet, and that all of the linesare shown in readable format, not the compact, efficient formatdiscussed above and shown in Appendix A.

The following is a control packet for associating ShortObjIDs with LongObject names:

-   -   S>C PO REGOBJIDCMD “Maclen” 5

Server 61 determines what short object ID (ShortObjID) to use for agiven object. With four pre-allocated Short ObjID values, server 61 canset up 252 other ID values. In the above command, the object whose longname is “Maclen” is assigned the ShortObjID of 5. This association isstored by client 60 in short object ID lookup table 110. The first twofields of the above command line, “PO” and “REGOBJIDCMD” indicate thatthe protocol object (PO) is to handle the command and indicate thecommand type (REGOBJIDCMD). The actual binary for the command is, inhexadecimal (except for the string):

-   -   S>C FF OD 06 Maclen 05

The following is a control packet containing a chat message:

-   -   C>S CLIENT TEXTCMD “ ” “Kyle, How is the weather?”        The ObjID field is set to CLIENT. The field following the        command type (TEXCMD) is unused in a text command from client to        server. Server 61 will indicate the proper ObjID of user A's        avatar when sending this message back out to the remote clients        who will receive this chat message. Thus, server 61 might        respond to the above command by sending out the following        control packet to the remote clients (assuming user A is named        “Judy”):    -   S>C CLIENT TEXTCMD “Judy” “Kyle, How is the weather?”        Of course, the text “Judy” need not be sent. If a short object        identifier has been registered with the client for Judy's        avatar, only the ShortObjID for “Judy” need be sent. User A may        also whisper a command to a single user who may or may not be in        the same room, or even in the same virtual world. For example:    -   C>S CLIENT WHISPERCMD “Kyle” “Kyle, How are you?”        Server 61 will route this message directly to the recipient        user. On the recipient client, the control packet for the        message will arrive with the ObjID of the sender (just like a        TEXTCMD), however, that client will know that it is a private        message because of the command type. The remote client receives        the following control packet from server 61:    -   S>C CLIENT WHISPERCMD “Judy” “Kyle, How are you?”        Other examples of control packets, such as those for entering        and exiting sessions and applications, are shown in Appendix B.        For state and property changes, objects have two kinds of        attribute variables. The first kind of attribute values are        “states” which represent boolean values. The second kind of        attribute values are called “properties” and may contain any        kind of information. Client 60 reports local attribute changes        to server 61 as needed and server 61 reports to client 60 the        attribute changes which might affect client 60. A different        command is used for each kind of attribute, as shown in Appendix        B.

From user A's point of view, avatars will appear and disappear from A'sview in a number of circumstances. For example, avatars enter and leaverooms and move in and out of visual range (as handled by crowd controlrules described below). Avatars also teleport from room to room, whichis different than moving in and out of rooms. Client 60 will send server61 the following location and/or room change commands under thecircumstances indicated:

-   -   LOCATIONCMD: normal movement of A's avatar    -   ROOMCHGCMD: changing rooms by walking    -   TELEPORTCMD: changing rooms and/or location by teleporting    -   TELEPORTCMD, ExitType=0: entering the application    -   TELEPORTCMD, EntryType=0: exiting the application.        When other, remote clients take such actions, server 61 sends        control packets to client 60, such as:    -   TELEPORTCMD: remote avatar teleported (EntryType or ExitType may        be 0 if the exit or entry was not visible to user A)    -   DISAPPEARACTORCMD: remote avatar was previously visible (in        range), but is now invisible (out of range) due to normal        (non-teleport) movement including having walked out of the room    -   APPEARACTORCMD: remote avatar was not visible, and is now        visible (command includes the remote avatar's Location and Room)    -   SHORTLOCCMD or LONGLOCCMD: remote avatar was visible before, and        is still now, but has moved.

Two methods exist for updating the position of an actor (avatar). TheLONGLOCCMD method uses full absolute position (X, Y, and Z) andorientation. The SHORTLOCCMD only updates the X and Y coordinates andthe orientation. In addition, the short method limits the change inposition to plus or minus 127 in the X and/or Y coordinates and/or+/−127 in the orientation. Client 60 sends a LONGLOCCMD to server 61 toupdate the client's position. Whenever possible, server 61 uses thecombined SHORTLOCCMD to update all of the visible avatars at once. If anavatar has moved too great a distance, or has moved in the Z direction,server 61 then uses a LONGLOCCMD for that avatar.

The following is an example of a control packet sent from client 60 toserver 61 to update user A's location:

-   -   C>S CLIENT LONGLOCCMD 2134 287 7199 14003        In the binary (given in hex), this is:    -   C>S 01 01 0856 011F 1C1F 36B3        Note that bytes are two digits and shorts (16 bits) are four        digits. They are separated by spaces here for clarity. The        actual packet would contain no spaces.

The Server often uses the combined short location update command. Thiscommand concatenates several ShortLocationCommands. Rather than sendinga command to each of the objects in question, a single combined commandis sent to the combine object (CO). This object takes the command andapplies it to a list of truncated commands. The truncated commandscontain a ShortObjID reference to the object to be moved and a change inthe X and Y positions and orientation. If server 61 wants to update thepositions of objects 56, 42 and 193, it would send the following:

-   -   S>C CO SHORTLOCCMD 56 −4 6 −10 42 21 3 −50 193 −3 −21 10

This command can contain a variable number of subcommands. Eachsubcommand is of fixed length so that the CO can find the length of itfrom a table check or other quick lookup method. The binary form of thiscommand is:

-   -   S>C FE 04 38 FC 06 F6 2A 15 03 CD C1 FD EB 10

When user A changes rooms by walking through a door, a RoomChangeCommandcontrol packet is sent by client 60 to server 61 to inform server 61that the room change occurred. The command specifies the new room andlocation for user A's avatar as follows:

-   -   C>S CLIENT ROOMCHNGCMD 01 25 1200 150 180

The first argument is the ObjID of the avatar that is leaving the room,the second argument is the command type (room change), and the thirdargument is the room that the avatar is entering. The next threearguments are the X, Y and Z positions at which to place the avatar inthe room. The last argument is the direction the actor is facing(orientation). Note that the first argument is always the ObjID for thelocal avatar, CLIENT=1.

When user A teleports from one room to another, the TeleportCommand issent by client 60 to server 61 to inform server 61 that the teleportoccurred. The method of leaving the room and entering the new one issent to server 61. This allows server 61 to inform other clients todisplay explosions or clouds, smoke or other indications of theteleportation appearance/disappearance of the avatar. The teleportcommand is as follows:

-   -   C>S CLIENT TELEPORTCMD 01 02 02 25 1200 150 180        The first argument is the ObjID of the avatar that is        teleporting, the second argument is the command type (teleport),        and the third argument is the room that the avatar is entering.        The next two arguments are the leaving method and the entering        method respectively. The next three arguments are the X, Y and Z        positions at which to place the actor in the room. The last        argument is the direction the actor is facing (orientation).        Note that the first argument is always the ObjID for the local        avatar, CLIENT=1.

Client 60 is responsible for implementing some sort of caching mechanismfor actors. When client 60 receives a TeleportCommand or AppearCommandfor an avatar that is appearing, it must first determine if it currentlyhas information for the specified object cached. If not, client 60 canissue a request for any needed information pertaining to the object.Suppose client 60 receives the following command specifying that “Mitra”has arrived at room 15:

-   -   S>C “Mitral” TELEPORTCMD 15 3 3 0 0 0 0        If client 60 does not have an entry cached for this object        (“Mitra”), or if the entry is dated, a request may be made for        pertinent information (here, the long object ID is used since        client 60 does not have the short object Id association for this        object):    -   C>S “Mitra” PROPREQCMD VAR_BITMAP        Server 61 will respond with a PropertyCommand as necessary to        communicate the required information. An example of pertinent        information above is a request for the avatar bitmap to use to        represent mitra.

Crowd control is one of the tougher problems solved by the presentsystem. Crowd control is handled using a number of commands. In atypical situation, the number of avatars in a room is too large to behandled by client 60 and displayed on display 122. The maximum number ofavatars, N, is determined by server 61, but might also be determined foreach client.

Server 61 addresses this problem by maintaining, for each user, a listof the N avatars nearest to the location of that user's avatar. Thislist may be managed by the server in any of a number of ways. When anavatar (B, for example) is removed from another user's (C, for example)list because avatar B can no longer be seen by C (i.e., B is no longerone of the N nearest avatars), Server 61 sends a DISAPPEARACTORCMD tothe object for avatar B on client C. This occurs as a consequence ofclient B changing rooms with a ROOMCHANGECMD or TELEPORTCMD, or due tocrowd control.

Client 60 does not necessarily delete an entry from remote avatar lookuptable 112 or short object ID lookup table 110 if a remote avatardisappears, but just marks it as being non-visible. In some cases, auser can see another user's avatar, but that other user cannot see thefirst user's avatar. In other words, visibility is not symmetric.However, chat exchange is symmetric, i.e., a user can only talk to thosewho can talk to the user.

When A's avatar is to be added to user B's lists when A becomes visibleto B by reason of movement, room change, crowd control, or the like,server 61 (more precisely the protocol object PO on server 61) sends aREGOBJIDCMD control packet to the PO of B's client 60 and B's client 60will add the association of A's avatar with a short object ID to shortobject ID lookup table 110. Server 61 also sends an APPEARACTORCMDcontrol packet to A's client giving the room and location of B. If A'sclient 60 does not have the appropriate information cached for B, A'sclient 60 sends a PropertyRequestCommand control packet to server 61asking for the properties of B, such as the bitmap to use to display B'savatar. Server 61 will return the requested information, which it mightneed to obtain from B's client 60. For example, the control packet:

-   -   PROPREQCMD VAR_BITMAP        might be used. Whenever possible, location updates from server        61 will be sent as SHORTLOCCMD control packets addressed to the        remote avatar using its ShortObjld and the        DisappearActorCommands, AppearActorCommands, and        TeleportCommands used to update client 60 on the status of        visible remote avatars will be combined as described for the        ShortLocationCommands.

The server 61 shown in FIG. 3 will now be described. Server 61 comprisesgenerally a network layer 62, protocol objects 63, user objects 64, roomobjects 65. In an object oriented software embodiment of the invention,each of these objects and layers are implemented as objects with theirspecific methods, data structures and interfaces. Where server 61 isimplemented on a hardware running the Unix operating system, theseobjects might be objects in a single process or multiple processes.Where server 61 is implemented on hardware running the Windows™operating system alone or in combination with the MS-DOS operatingsystem or the like, the layers and objects might be implemented as OLE(Object Linking and Embedding) objects.

One protocol object 63 and one user object 64 are instantiated for eachuser who logs into server 61. Network layers 62 accepts TCP/IPconnections from clients 60. A socket is opened and command buffers areallocated for each client 60. Network layer 62 is responsible forinstantiating a protocol object 63 for each TCP/IP socket established.This layer handles the sending and receiving of packets, such as controlpackets, document packets and stream packets, over the network. Allsockets are examined by server 61 on a periodic basis; completed controlpackets received from a client 60 are processed by server 61, andoutgoing control packets to a client 60 which are pending are sent.

Protocol object 63 handles translation of internal messages to and fromthe cryptic and compressed form of the control packets which are sentover network connection 80, as explained in Appendices A and B. Protocolobject 63 handles all session initialization and authentication for itsclient 60, and is responsible for instantiating a user object 64 forauthenticated users.

User object 64 tracks the location of its user's avatar, which includesat least the room in which the user is located, the user's coordinatesin the room and the user's orientation in that room. User object 64 alsomaintains a list of the N nearest neighboring remote avatars (i.e.,avatars other than the avatar for the user object's client/user) in theroom. This list is used to notify the user object's client 60 regardingchanges in the N closest remote avatars and their locations in the room.The list is also used in disseminating text typed by the user to onlythose users nearest him or her in the room. This process of notifyingclient 60 of only the N nearest neighbors is handled as part of crowdcontrol.

One room object 65 is instantiated for each room in rooms database 70and the instantiation is done when server 61 is initialized.Alternatively, room objects can be instantiated as they are needed. Asexplained above, the term “room” is not limited to a visualization of atypical room, but covers any region of the virtual world which could begrouped together, such as the underwater portion of a lake, a valley, ora collection of streets. The room object for a specific room maintains alist of the users currently located in that room. Room object 65periodically analyzes the positions of all users in the room using acell-based algorithm, and sends a message to each user object 64corresponding to those users in the room, where the message notifies theuser object of its user's N nearest neighbors.

Periodically, the locations of the users in each room are examined and asquare two-dimensional bounding box is placed around the users' currentlocations in the room. This square bounding box is then subdivided intoa set of square cells. Each user is placed in exactly one square. Then,for each user, the cells are scanned in an outwardly expanding wavebeginning with the cell containing the current user of interest, untilat least N neighbors of that user are found. If more than N are found,the list of neighbors is sorted, and the closest N are taken.

One or more world object 66 may be instantiated at the time server 61 isstarted. The world object maintains a list of all the users currently inthe world and communicates with their user objects 64. The world objectalso maintains a list of all the rooms in the world and communicateswith the room objects 65 for those rooms. The world object periodicallyinitiates the analysis of user positions in each room and subsequentupdating of avatar information to clients (60). In addition, the worldobject periodically initiates the collection of statistics on usage (forbilling, study of which rooms are most popular, security logs, etc.)which are logged to a file.

Server 61 also has a rooms/world database 92 which is similar to therooms/world database 70 in client 60. Server 61 does not need theprimitives databases because there is no display needed at the server.Server 61 does, however, include a user state database 90, whichmaintains state information on each user, such as address, log-in time,accounting information, etc.

Several interconnections are shown in FIG. 3. Path 81 between a protocolobject 63 and a user object 64 carries messages between a client 60 andthe user object 64 representing that client (before or after having beentranslated by a protocol object 63). Typical messages from the client tothe user object include:

-   -   Move my avatar to (x, y, z, orientation)    -   Send a text message to all neighboring remote avatars

Typical messages from the user object to the client are:

-   -   User X teleported into your view at (x, y, z, orient.)    -   User Z has just left your view    -   User W has moved to (x, y, z, orientation)    -   Here is text from user Y    -   Here is private text (whispered) from user A

The path 82 between a client 60 and a user object 64 other than its ownuser object 64 is used to send whispers from user to user. Path 83 isused for internal messages sent directly between user objects 64.Messages taking this path typically go from a given user to those userswho are among its N nearest neighbors. Typical messages include:

-   -   Here is text I have typed    -   I have just teleported to a given room and location    -   I have changed my state (logged in, logged out, etc.)    -   I have changed one or more of my properties

Path 84 is used for messages between a user object 64 and a room object65. User objects 64 communicate their location to the room 65 they arecurrently in. Periodically, the room object will notify the user objectof the identities and locations of the users' N nearest neighbors.Messages from the user object to the room include:

-   -   I have just teleported either into or out of this room    -   I have just entered this room    -   I have just left this room    -   My new location in this room is (x, y, z, orientation)

The only message that passes from the room object to a user object isthe one that notifies the user of its N nearest neighbors. Path 85 isused for communications between protocol objects and world object 66.Protocol object 63 can query world object 66 regarding the memoryaddress (or functional call handle) of the user object 64 representing agiven user in the system. This is the method that is used to send awhisper message directly from the protocol object to the recipient userobject. Path 86 is used for communications between user object 64 andworld object 66 to query the world object regarding the memory addressor function call handle of the room object 65 representing a given roomin the world. This is required when a user is changing rooms. FIG. 5 isan illustration of the penguin avatar rotated to various angles.

The above description is illustrative and not restrictive. Manyvariations of the invention will become apparent to those of skill inthe art upon review of this disclosure. The scope of the inventionshould, therefore, be determined not with reference to the abovedescription, but instead should be determined with reference to theappended claims along with their full scope of equivalents.

APPENDIX A Client/Server Control Protocol Commands (in BNF) ValidCommandTypes are integers between 0 and 255. Several of these are shownbelow as part of the BNF (Backus-Nauer Format) description of thecommand structures. Per convention, words starting with uppercasecharacters are non-terminals while those in quotes or in lowercase areterminal literals. Basics a | b = Either a or b. ″abc″ = The exactstring of characters a, b and c in the order shown. a+ = One or moreoccurrences of a. a* = Zero or more occurrences of a. 10 = A number 10.In the ASCII protocol, this is the ASCII string ″10″, in the binaryform, it is a byte with a value of 10. N . . . M = A numerical rangefrom N to M.  Equivalent to: N | N + 1 | N + 2| 1 . . . | M − 1 | MCommand Structures Packet = PktSize Message PktSize = UInt8 (sizeincludes PktSize field) Message = ObjID Command ObjID = LongObjID |ShortObjID LongObjID = 0String ShortObjID = UInt8 Command = CommandTypeCommandData CommandType = UInt8 [Other commands might be added tothese:] Command = LongLocationCommand | ShortLocationCommand |StateCommand | PropertyCommand | PropertyRequestCommand |CombinedCommand | RoomChangeCommand | SessionInitCommand |SessionExitCommand | ApplicationInitCommand | ApplicationExitCommand |DisappearActorCommand | AppearActorCommand | RegisterObjIdCommand |TeleportCommand | TextCommand | ObjectInfoCommand | LaunchAppCommand |UnknownCommand | WhisperCommand | StateRequestCommand TeleportCommandLocation = TELEPORTCMD NewRoom ExitType EntryType RoomChangeCommand =ROOMCHNGCMD NewRoom Location LongLocationCommand = LONGLOCCMD LocationDisappearActorCommand = DISAPPEARACTORCMD AppearActorCommand =APPEARACTORCMD NewRoom Location Location = X Y Z Direction X, Y, Z,Direction = SInt16 StateCommand = STATECMD SetFlags ClearFlags SetFlags,ClearFlags = UInt32 PropertyCommand = PROPCMD Property+PropertyRequestCommand = PROPREQCMD VariableID* StateRequestCommand =STATEREQCMD Property = VariableID VariableValue VariableID =ShortVariableId | LongVariableId ShortVariableId = UInt8 LongVariableId= 0String VariableValue = String ShortLocationCommand = SHORTLOCCMDDeltaX DeltaY DeltaO DeltaX, DeltaY = SByte DeltaO = SByte (phis 128 to−128 degrees) CombinedCommand = CombinedLocationCommand |CombinedAppearCommand | CombinedTeleportCommand |CombinedDisappearCommand | UnknownCombinedCommandCombinedLocationCommand = SHORTLOCCMD AbbrevLocCommand+ AbbrevLocCommand= ShortObjID DeltaX DeltaY DeltaO CombinedAppearCommand = APPEARACTORCMDAbbrevAppearCommand+ AbbrevAppearCommand = ShortObjID NewRoom LocationCombinedDisappearCommand = DISAPPEARACTORCMD AbbrevDisappearCommand+AbbrevDisappearCommand = ShortObjID CombinedTeleportCommand =TELEPORTCMD AbbrevTeleportCommand+ AbbrevTeleportCommand = ShortObjIDNewRoom ExitType EntryType Location [for now:] UnknownCombinedCommand =0 . . 3, 5 . . 10, 13 . . 17, 19 . . 255 NewRoom = UInt16 ExitType,EntryType = UInt8 SessionInitCommand = SESSIONINITCMD Property+SessionExitCommand = SESSIONEXITCMD Property+ ApplicationInitCommand =APPINITCMD Property+ ApplicationExitCommand = APPEXITCMD Property+RegisterObjIDCommand = REGOBJIDCMD String ShortObjID TextCommand =TEXTCMD ObjID String WhisperCommand = WHISPERCMD ObjID StringLaunchAppCommand = LAUNCHAPPCMD String [for now:] UnknownCommand = 0,15, 20 . . 255 String = StringSize Char* StringSize = UInt8 (size ofstring EXCLUDING field) StringSize Char = C datatype char UInt32 = 0 . .4294967299 (32-bit unsigned) SInt32 = −2147483650 . . . 2147483649(32-bit signed value) UInt16 = 0 . . 65535 (16-bit unsigned value)SInt16 = −32768 . . 32767 (16-bit signed value) UInt8 = 0 . . . 255(8-bit unsigned value) SByte = −128 . . 127 (8-bit signed value)LONGLOCCMD = 1 STATECMD = 2 PROPCMD = 3 SHORTLOCCMD = 4 ROOMCHNGCMD = 5SESSIONINITCMD = 6 SESSIONEXITCMD = 7 APPINITCMD = 8 APPEXITCMD = 9PROPREQCMD = 10 DISAPPEARACTORCMD = 11 APPEARACTORCMD = 12 REGOBJIDCMD =13 TEXTCMD = 14 LAUNCHAPPCMD = 16 WHISPERCMD = 17 TELEPORTCMD =18STATEREQCMD =19 CLIENT = 1 CO = 254 PO = 255

APPENDIX B Additional Control packet Examples B.1. State and PropertyChanges  State changes change a string of boolean values. Either theClient or the Server can send these. Each object can have up to 32different state values. These are represented as bits in a bit string.If the Client wants to set bit 3 of the state variable of an object,137, it sends the following:  C>S 137 STATECMD 4 0 In binary (given ashexadecimal) this is:  C>S 89 02 00000004 00000000  Properties take morepossible values than states. Similar to state variables, properties arereferenced in order. Variables may be represented as a predefined ID(counting from 1) or by an arbitrary string.  Assuming that the Clienthas changed its local copy of a variable (with the tag 6) in object 23.It would send a command to the Server as follows:  C>S 23 PROPCMD 6 ″anew value″  The variable ID is a predefined shorthand name for avariable name. These names are predefined and hardcoded into the Client.They generally can't be changed without changing the Client executable.An old Client that sees a variable ID it does not know must ignore thecommand Some variables will always be defined, ″bitmap″ for example.These are defined in a fixed manner at the Client level. The Client willsimply send these variable IDs to the Server which will transparentlypass them on to other Clients. The currently defined variable IDs are:VAR_APPNAME = 1 // Name of Application to run VAR_USERNAME = 2 // User'sid. VAR_PROTOCOL = 3 // Version of protocol used by client (int)VAR_ERROR = 4 // Used in error returns to give error type VAR_BITMAP = 5// Filename of Bitmap VAR_PASSWORD = 6 // User's password VAR_ACTORS = 7// Suggested # of actors to show client (N) VAR_UPDATETIME = 8 //Suggested update interval (* 1/10 sec.) VAR_CLIENT = 9 // Version of theclient software (int) The client can request the values for one or moreproperties with the PROPREQCMD:  C>S ″Fred″ PROPREQCMD VAR_BITMAP  S>C″Fred″ PROPCMD VAR_BITMAP ″skull.bmp″ A PROPREQCMD with no parameterswill result in a PROPCMD being returned containing all the properties ofthe object the request was sent to. If a PROPREQCMD is made with arequest for a property that doesn't exist, an empty PROPCMD will bereturned. A STATEREQCMD requests the Server to respond with the currentstate. B.2. Beginning and Exiting Sessions To begin a session, theClient requests a connection from the Server. After the connection hasbeen established, the Client sends a SessionInitCommand. TheSessionInitCommand should contain the User's textual name (preferably,this textual name is unique across all applications) and the version ofthe protocol to be used. For example, the User named ″Bo″ hasestablished a connection and would now like to initiate a session. C>SCLIENT SESSIONINITCMD VAR_USERNAME ″Bo″ VAR_PROTOCOL ″11″ Currentlydefined variables for the SessionInitCmd are: VAR_USERNAME The accountname of the user VAR_PASSWORD User password (preferably a plain textstring) VAR_PROTOCOL The protocol version (int) VAR_CLIENT Version ofthe client software being used (int) Note that the protocol defines thevalue as a string, but the (int) comment is a constraint on the valuesthat may be in the string. The Server will send an ack/nak indicatingthe success of the request. An ack will take the form:  S>C CLIENTSESSIONINITCMD VAR_ERROR 0 A nak will take the form: S>C CLIENTSESSIONINITCMD VAR_ERROR 1 where the value of VAR_ERROR indicates thenature of the problem. Currently defined naks include: * ACK 0 It's OK *NAK_BAD_USER 1 User name already in use  * NAK_MAX_ORDINARY 2 Too manyordinary users * NAK_MAX_PRIORITY 3 Too many priority users *NAK_BAD_WORLD 4 World doesn't exist * NAK_FATAL 5 Fatal error (e.g.can't instantiate user) * NAK_BAD_PROTOCOL 6 Client running old or wrongprotocol * NAK_BAD_CLIENTSW 7 Client running old, or wrong version *NAK_BAD_PASSWD 8 Wrong password for this user * NAK_CALL_BILLING 9Access denied, call billing * NAK_TRY_SERVER 10 Try different serverB.3. Beginning and Exiting Application To begin an application, theClient must have already established a session via theSessionInitCommand. To begin an application, the Client sends anApplicationInitcommand specifying the desired application: C>S CLIENTAPPINITCMD VAR_APPNAME ″StarBright″ The Server will respond with anack/nak to this command using the same technique discussed under sessioninitialization. B.4. Launching an Outside Application  The Server maytell the Client to launch an outside application by sending theLaunchAppCommand to the Protocol Object. For example:  S>C POLAUNCHAPPCMD ″Proshare″

What is claimed is:
 1. A client computing device configured to enable afirst user controlling a first avatar in a virtual space to performactions in the virtual space, the virtual space comprising a pluralityof avatars of a plurality of other users, each user of the plurality ofother users being associated with an avatar representing said each userin the virtual space, the first user being associated with the firstavatar, the client computing device comprising: an input device; adisplay; data storage storing: instructions, and a rooms databasedefining constraints on movements of the first avatar in the virtualspace, the rooms database comprising data defining appearances of aplurality of objects in the virtual space, the plurality of objectscomprising a first object; and at least one processor programmed usingthe instructions to: cause the first avatar to move in the virtual worldin response to first avatar positioning data from the first user, causethe head of the first avatar to rotate independent from movement of thefirst avatar, in response to first avatar head direction data from thefirst user; monitor viewpoint of the first avatar; determine one or moreavatars of the other users to be displayed on the display based at leastin part on the viewpoint; and render on the display the first object andthe one or more avatars of the other users to be displayed; receive aselection of the first object through the input device; cause an actionto be performed in response to the selection of the first object,wherein the first object comprises a portion having an appearanceconveying a message.
 2. A client computing device according to claim 1,wherein the message is at least partially textual, the at least oneprocessor is further programmed using the instructions to display theportion having the appearance conveying the message, and the messagerefers to the action.
 3. A client computing device according to claim 2,wherein the at least one processor is further programmed using theinstructions to cause the action in response to the selection being madeby performing a selection action through a computer pointing device onthe portion having the appearance conveying the message.
 4. A clientcomputing device according to claim 2, wherein the first object has atleast two dimensions.
 5. A client computing device according to claim 2,wherein the first object is three-dimensional.
 6. A client computingdevice according to claim 5, wherein the data storage further stores anavatar image database comprising entries for rendering at least someavatars of the plurality of other users.
 7. A client computing deviceaccording to claim 5, wherein the first avatar and the plurality ofother avatars are multi-dimensional avatars.
 8. A client computingdevice according to claim 1, wherein the action comprises displayingadditional information on the display.
 9. A client computing deviceaccording to claim 1, wherein the action comprises rendering additionalinformation for the first user.
 10. A client computing device accordingto claim 1, wherein the rooms database comprises data obtained from acentral server.
 11. A client computing device according to claim 1,wherein the at least one processor is further programmed using theinstructions to determine the one or more avatars of the other users tobe displayed on the display based on available computing resources ofthe client computing device.
 12. A method for a first user at a clientcomputing device controlling a first avatar of a virtual space to act inthe virtual space, the virtual space comprising a plurality of avatarsof a plurality of other users, each user of the plurality of other usersbeing associated with an avatar of the plurality of avatars representingsaid each user in the virtual space, the first user being associatedwith the first avatar, the virtual space further comprising the firstavatar, the method comprising steps of: storing in the client computingdevice a rooms database defining constraints on movements of the firstavatar in the virtual space, the rooms database further comprising datadefining appearances of a plurality of objects in the virtual space, theplurality of objects comprising a first object; executing instructionson the client computing device to move the first avatar in the virtualworld in response to first avatar positioning data received through aninput device of the client computing device; executing instructions onthe client computing device to rotate head of the first avatar in thevirtual world in response to first avatar head direction data receivedthrough an input device of the client computing device, wherein the headof the first avatar is rotatable independent from positional movement ofthe first avatar; executing instructions on the client computing deviceto determine one or more avatars of the other users to be displayed on adisplay device of the client computing device; executing instructions onthe client computing device to monitor viewpoint of the first avatar;executing instructions on the client computing device to determine oneor more avatars of the other users to be displayed on the display basedat least in part on the viewpoint; executing instructions on the clientcomputing device to receive through the input device a selection of thefirst object; and executing instructions on the client computing devicecausing an action to be performed in response to the selection, whereinthe first object comprises a portion having appearance conveying amessage.
 13. A method according to claim 12, wherein the message refersto the action.
 14. A method according to claim 13, wherein the firstobject is three-dimensional.
 15. A method according to claim 14, themethod further comprising: storing at the client device an avatar imagedatabase comprising entries for rendering at least some avatars of theplurality of other users.
 16. A method according to claim 14, whereinthe first avatar and the plurality of other avatars aremulti-dimensional avatars.
 17. A method according to claim 12, whereinthe action comprises displaying additional information on the displaydevice.
 18. A method according to claim 12, wherein the step ofexecuting instructions on the client computing device to determine theone or more avatars of the other users to be displayed on the displaydevice of the client computing device comprises executing instructionsto determine the one or more avatars of the other users displayable onthe display device based at least in part on networking resources of theclient computing device.
 19. A method according to claim 12, furthercomprising executing instructions on the client computing device toreceive at the client computing device the rooms database from a centralserver over a computer network.
 20. An article of manufacture comprisinga machine readable memory device storing computer-readable informationfor performing a method for a first user at a client computing devicecontrolling a first avatar of a virtual space to act in the virtualspace, the virtual space comprising a plurality of avatars of aplurality of other users, each user of the plurality of other usersbeing associated with an avatar of the plurality of avatars representingsaid each user in the virtual space, the first user being associatedwith the first avatar, the virtual space further comprising the firstavatar, the computer-readable information comprising: a rooms databasedefining constraints on movements of the first avatar in the virtualspace, the rooms database further comprising data defining appearancesof a plurality of objects in the virtual space, the plurality of objectscomprising a first object; machine-executable instructions to move thefirst avatar in the virtual world in response to first avatarpositioning data received through an input device of the clientcomputing device; machine-executable instructions to rotate head of thefirst avatar in the virtual world in response to first avatar headdirection data received through an input device of the client computingdevice, wherein the head of the first avatar is rotatable independentfrom position movement of the first avatar in the virtual space;machine-executable instructions to determine one or more avatars of theother users to be displayed on a display device of the client computingdevice; machine-executable instructions to monitor viewpoint of thefirst avatar; machine-executable instructions to determine one or moreavatars of the other users to be displayed on the display based at leastin part on the viewpoint; machine-executable instructions to receivethrough the input device a selection of the first object; andmachine-executable instructions causing an action to be performed inresponse to the selection; wherein the first object comprises a portionhaving appearance conveying a message.
 21. A method for operating aserver to enable a plurality of users to interact in a virtual space,wherein each user has a computer associated therewith, wherein eachcomputer has a client process associated therewith, wherein each clientprocess has an avatar associated therewith, wherein the server has aprocess associated therewith, and wherein each client process is incommunication with the server process, comprising: (a) receiving, fromeach client process by the server process, data indicating a position ofthe avatar associated with the client process; and (b) disseminating inreal-time less than all of the positions of the avatars not associatedwith a particular client process to each of the other client processesso that the particular client process can determine from the positions aset of avatars that are to be displayed.
 22. A software program recordedon a machine-readable medium for operating a server to enable aplurality of users to interact in a virtual space, wherein each user hasa computer associated therewith, wherein each computer has a clientprocess associated therewith, wherein each client process has an avatarassociated therewith, wherein the server has a process associatedtherewith, and wherein each client process is in communication with theserver process, wherein the software program comprises instructions for:(a) receiving from each client process by the server process, dataindicating a position of the avatar associated with the client process;and (b) disseminating in real-time the positions of less than all of theavatars not associated with a particular client process to each of theother client processes so that the particular client process candetermine from the positions a set of avatars that are to be displayed.23. A system for displaying interactions in a virtual world among alocal user avatar of a local user and a plurality of remote user avatarsof remote users, comprising: a database storing information associatedwith one or more avatars, each user being associated with a threedimensional avatar; a memory storing instructions; and a first processorprogrammed using the instructions to: receive position informationassociated with less than all of the remote user avatars in one or moreinteraction rooms of the virtual world, wherein the processor does notreceive position information associated with at least some of the remoteuser avatars in the virtual world, each avatar of the at least some ofthe remote user avatars failing to satisfy a condition, receiveorientation information associated with less than all of the remote useravatars, wherein the processor does not receive orientation informationassociated with at least some of the remote user avatars in the virtualworld, generate on a graphic display a rendering showing the positionand orientation of at least one remote user avatar, and switch between arendering on the graphic display that shows the virtual world to thelocal user from a perspective of the local user avatar and a renderingthat allows the local user to view the local user avatar in the virtualworld from a perspective of a remote user avatar from the plurality ofremote user avatars.
 19. A system for displaying interactions in avirtual world among a local user and a plurality of remote users, thesystem comprising: a database storing information associated with one ormore avatars, each user being associated with a three dimensionalavatar; a memory storing instructions; and a processor programmed usingthe instructions to: receive position information associated with lessthan all of the remote user avatars in one or more rooms of the virtualworld where user interactions take place, wherein the processor does notreceive position information associated with at least some of the remoteuser avatars in the virtual world, receive orientation informationassociated with less than all of the remote user avatars in the one ormore rooms of the virtual world where user interactions take place,wherein the processor does not receive orientation informationassociated with at least some of the remote user avatars in the virtualworld, generate on a graphic display a rendering showing the positionand orientation of at least one remote user avatar, and switch between arendering in which a first perspective view of a local user avatar ofthe local user is displayed and a rendering in which a secondperspective view of the local user avatar of the local user isdisplayed.